i think we should also add:

• making a tentative plan of high profile features for every release
• appoint one contributor to be the release manager that keeps an eye on the above list, keeping an eye on any merged features that are not stabilizing in time and who generally keeps an eye on the release schedule and communication with the entire community
• creation of an invite only, but public list for large projects using Symfony2 components to help in coordinating releases (there should also be an invite only non public list for security topics, but this is likely beyond the scope of this document)
• not sure if this needs to be mentioned, but maybe this document should also mention that there should be an UPGRADING guide with every release

finally i think it would be good to add an image with an example showing how f.e. the releases would look like starting 2.3 for the next 5 years to better visualize the time overlap.

It isn't only for the code, it is also for the documentation and the complete 'environment' around SF2. I think it is better to put this under 'Community' or create a new heading.

I see you're proposing to add predictability and doing so through a timed release, but I'd rather see predictability defined as a specified target feature list. Define a list of features and bugfixes you'd like to see in the next release. When those are done, make the release. Maybe a compromise would be to define a list of features that could take approximately 6 months to complete?

Making a release every 6 months is predictable, but then requires going back through the changelog to find what things were changed. It can leave features incomplete or left out even if they're close to completion. I'd be concerned with a 6 month schedule you'll get releases where it's hard to tell from version to version whether it's worthwhile to make the upgrade. If you define a list of features that make a release worthwhile, then you'll know as a user that each release has a feature set that's been considered carefully to be worthwhile feature set for a milestone.

@deekayen a target feature list does not provide any predictability as you cannot predict how much time will be needed to make the feature ready, especially for projects where people are contributing on their free time.
This is exactly the reason why it took us 1 year to release 2.1 whereas we also wanted to try making it 6 months at the time 2.0 was released (and waiting for the form changes to be ready, some features merged in August 2011 were still not shipped to the users)

A list does provide predictability, just a different kind. You're defining predictability as a timeframe. I'm defining predictability as a listed feature set. If there's a take-away, it's not that you should re-define predictability. If the time between releases is too far, I'd say too many features were defined in the list. That's just a lesson for defining future lists.

@deekayen the issue is that we do have the resources to promise a release every 6 months .. we do not have the resources to promise any features .. let alone providing these features in a reasonable time frame .. i do agree that we should try to specify the "highlight" features we are working on .. but i dont think it makes sense to promise them .. or delay releases until they are ready.

@deekayen If you say "We will ship when all these features are ready", it does not give any predictability to projects relying on Symfony as they have no way to predict when this will happen.

And it is not that there were too many stuff on the list. The blocking point was the form refactoring which took longer than expected first.

I think you're diluting the value of a release by making them not uniform anymore. Again, yes, they'll be uniform by time frame, but they won't be uniform in release value. Some will have just a few bug fixes while others will have major feature enhancements or API changes. What you'll be breaking the predictability of evaluating the value of going through the effort of doing the upgrade between versions.

well past experience tells us we have a good stream of small and big stuff coming in .. but people come and go .. and the focus of the new people is different. so i do think we can guarantee that every 6 months we have some nice new features.

@deekayen Starting with 2.3, the effort to upgrade should be very low as maintaining BC will become mandatory.

@lsmith77 I've just added an image showing the next few releases.

@wouterj I've moved the file under the community section.

@fabpot the meaning of the different colors in the image is missing (it should be explained in the doc rather than the image to allow translations)

I'm happy to proof this and merge it in (and I can also look at @stof's last comment). But, have we officially decided and agreed on this approach? I honestly don't think we'll choose a very different path, but I don't want to merge this until we're all sure.

Thanks!

@weaverryan I've talked about this approach at SymfonyLive London and San Francisco, I posted this on the dev mailing-list a long time ago, and we now have this PR waiting for comments for a very long time too. So, I think we can safely merge this and make it official. There are a couple of interesting comments made by @lsmith77 that I think need to be taken into account, but probably not in this document.

Perfect! I've patched this into the 2.0 branch at sha: 717dfb2 with a few minor syntax tweaks.

If anyone spots any other changes, let me know or open a PR :).

Thanks everyone!